1. Field of the Invention
The present invention relates generally to a computer development, and more particularly to providing a system and method for assessing software components that are to be integrated with other components.
2. Background of the Invention
The use of third party software components, such as commercial-off-the-shelf (COTS) products, has become more and more common in the building and maintenance of large software systems. Corporate downsizing and decreased government budgets, as well as the upward spiraling costs of building and maintaining large software systems, have necessitated a reuse of existing software components. Generally, reuse of existing software components is more cost effective than creating new software components. Reuse of existing software can also reduce the time-to-market for the software system. For these reasons, the use of COTS software components has become increasingly prevalent in recent years, which is evidenced by the fact that most of today's large software systems incorporate COTS components, along with legacy software and custom-built components.
COTS components may be defined as components that are bought from a third-party vendor and integrated into a new system. A COTS component may be as small as a routine that computes a square root of a number or as large as an entire library of functions. Generally, the COTS component of a new system is an existing product created by people outside of the software development organization that develops or used the new system.
Associated with the widespread use of COTS component is a new set of problems that do not exist if large systems are built and maintained using custom-built software. For example, a source code for a COTS component is rarely made available to a buyer. Thus, the COTS component must be analyzed and tested as a “black box.” Determining the COTS component's behavior can be a challenge, particularly if the COTS component does not behave as expected. Even if the source code were available, determining how the COTS component will behave once the COTS component is integrated into a software system can still be difficult.
In addition, updates and evolution of a COTS component by the vendor can result in further modification to the software system. In some cases, a new functionality of an updated COTS component could be detrimental to the software system.
Furthermore, the vendor often fails to provide a correct or complete description of the COTS component's behavior. This can result in the buyer of the COTS component having to guess how the COTS component is meant to be used or how the COTS component is supposed to behave. Worse yet, the buyer could end up using the COTS component in a manner not intended by the vendor. Unanticipated uses could compromise the reliability of both the COTS component and the software system into which the COTS component is integrated.
Moreover, maintenance can become an issue because the vendor may not correct defects or add enhancements as the buyer needs them. Developers in the organization that purchased the COTS component may be forced to make modifications themselves, which can be difficult if the component's source code is unavailable or if the component's specification is poor.
Clearly, integrating COTS components into a software system is prone to errors that can require a significant amount of coding and can be problematic to test properly.